home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
kermit.columbia.edu
/
kermit.columbia.edu.tar
/
kermit.columbia.edu
/
newsgroups
/
misc.20030409-20031118
/
000038_fdc@columbia.edu_Thu May 1 13:27:42 EDT 2003.msg
< prev
next >
Wrap
Text File
|
2003-11-18
|
4KB
|
98 lines
Article: 14253 of comp.protocols.kermit.misc
Path: newsmaster.cc.columbia.edu!news.columbia.edu!news-not-for-mail
From: fdc@columbia.edu (Frank da Cruz)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: Changed behavior of receive/transmit move-to
Date: 1 May 2003 13:10:10 -0400
Organization: Columbia University
Lines: 81
Message-ID: <b8rkdi$mo0$1@watsol.cc.columbia.edu>
References: <b8rfll$kfv$1@cpimail.cpicorp.com>
NNTP-Posting-Host: watsol.cc.columbia.edu
X-Trace: newsmaster.cc.columbia.edu 1051809012 5710 128.59.39.139 (1 May 2003 17:10:12 GMT)
X-Complaints-To: postmaster@columbia.edu
NNTP-Posting-Date: 1 May 2003 17:10:12 GMT
Xref: newsmaster.cc.columbia.edu comp.protocols.kermit.misc:14253
In article <b8rfll$kfv$1@cpimail.cpicorp.com>,
Derek Chen-Becker <dbecker@cpicorp.com> wrote:
: The behavior of the set receive move-to command seems to have
: changed between c-kermit 8.206 and 8.209. It used to resolve the full
: path of the move-to target upon each transfer, and now it appears to
: resolve it on login through IKSD. We have a directory structure like this:
:
: ~/
: ~/a
: ~/a/incoming
: ~/a/complete-rx
: ~/a/outgoing
: ~/a/complete-tx
: ~/b
: ~/b/incoming
: ~/b/complete-rx
: ~/b/outgoing
: ~/b/complete-tx
:
: The .kermrc for the account had lines like:
:
: set receive move-to complete-rx
: set send move-to complete-tx
:
: Under 8.206 we could change to directory "a" or directory "b" and issue
: a send command like "send test.txt incoming/test.txt". The incomplete
: file during transfer would sit in the appropriate incoming directory and
: then would be moved to the approprate complete-rx directory on
: completion. Under 8.209 the completed files sit in the incoming
: directory unless we create a "complete-rx" directory in the home:
:
: ~/complete-rx
:
: and then they move there no matter which incoming directory they
: arrived in.
:
I would venture to say that the behavior you were relying on was not
intentional. Although my notes don't show it, I suspect that somebody else
-- maybe even me -- was surprised when a relative directory name was not
resolved in the context in which the command was given, especially since
after changing contexts it might not be be valid.
: If this was for one or two sites we could work around it by creating
: different accounts for each one, but this is for 1200+ sites and one
: account makes it managable.
:
Well, when you put it that way I can see how deferred evaluation could be
useful too, in a use-at-your-own-risk sort of way. But this turns out to
be a rather tricky question, since immediate and deferred evaluation can
be applied independently to the context (current directory for relative
filespecs) and to any variables in the MOVE-TO or RENAME-TO string, e.g.:
SET RECEIVE RENAME-TO \v(filename)_\v(ndate)_\v(ntime)_\v(userid)_\v(pid)
Deferring evaluation of the MOVE/RENAME-TO string until it is used means
that an error might not be detected until hours into the operation, after
everybody has gone home.
: If I could remotely set the send/receive move-to destinations, that
: might work, too.
:
That would be a change too. But clearly changes are necessary, especially
since in researching this I discovered that the SET RECEIVE RENAME-TO
example (which is taken from the C-Kermit 7.0 update notes) is broken too.
My first reaction would be accept the MOVE-TO/RENAME-TO argument as-is
at parse time, with no checking, and then evaluate it upon use. This way,
if you give an absolute pathname, it is constant; if you give a
relative one, its resoluation varies with the context. To extend same
flexiblity to variables in the string, such as \v(time), we'd have to
evaluate them at *parse* time. If the user wanted to defer evaluation
until use, s/he'd have to double the backslash. A tad hard to explain,
but it leaves the user with every combination of choices. If I get a
chance to work on the code again, I'll try this and see how it feels.
In the meantime, I'd recommend you fall back to whatever version of
C-Kermit you were using before.
Thanks for the report.
- Frank